This invention relates generally to Intelligent Networks for telecommunications and, in particular, to load sharing between a group of Service Control Points for traffic management control within the network.
With reference to FIG. 1, as is well known, an Intelligent Network (IN) includes various network elements (NEs), such as, Service Switching Points (SSPs), Service Control Points (SCPs), Adjuncts, Intelligent Peripherals (IPs), and Mediation Points (MPs). The IN service offering implies cooperation between different network elements, typically the SSPs and SCPs, using the Common Channel Signaling No. 7 (CCS7) network protocols.
An Operations, Administration, and Maintenance (OAM) management environment is characterized by functionality to ensure reliable operation of the IN. Telecommunication Management Network (TMN) components providing the network OAM management include a Services Management System (SMS), Surveillance and Testing Operations Systems, and Network Traffic Management (NTM) Operations Systems (OSs). Measurements, logs and alarms related to network operations and services are generated by the NEs and collected by the OSs for OAM management. The Surveillance and Testing Operations Systems (OSs) provide fault management. The main objective of the Network Traffic Management OSs is to manage overload controls at the various NEs and to ensure service reliability and network integrity.
The NTM consists of monitoring and control functions aimed at the detection of abnormal load conditions and excessive traffic congestion, activation, de-activation and monitoring of overload controls. The IN NTM requirements in [1] GR-1298-CORE, Advanced Intelligent Network (AIN) Switching Systems Generic Requirements, Bellcore, Issue 3, July , 1996; [2] Draft Revised ITU-T Recommendation Q.1218, Interface Recommendation for Intelligent Network CS-1. COM 11-R 104E, May 1995; and [3] ITU-T Recommendation E.412, Telephone Network and ISDN Quality of Service, Network Management and traffic Engineering, Network Management Controls, emphasize the need for automatic call-associated query and non-call-associated signaling messages limiting controls triggered by detected congestion conditions at one or more connected equipment. These controls minimize congestion conditions, due to traffic overloads (or reduced call processing capacity) at the NE, from spreading to the subtending NEs and throughout the rest of the network.
Automatic Code Gapping (ACG) is a network management mechanism used in the control of network congestion. For example, if an SCP becomes congested with queries, it can issue a request to slow down or stop a SSP from sending queries for a predetermined period. When an SCP finds that it is being overloaded with queries, it automatically issues a request that the SSP slow down or stop sending queries, matching a certain criterion or criteria, for a given duration of time. The criteria and the request can also be manually initiated from the service management system (SMS). Both automatic- and manually-initiated requests are relayed from the SCP to the SSP in the form of an ACG message. From the SCP/SMS initiated ACG request messages, a list of controls is created and maintained against which pending SCP destined queries are checked. During call processing, prior to sending an IN query, the ACG controls are checked to determine whether the query is to be gapped (that is, blocked). If the criteria specified in the control matches that for the pending query, then the query is gapped, and either IN final treatment or Default Routing is applied to the call.
Implementation of the Automatic Code Gapping (ACG) mechanism consists of procedures in the SCPs for detecting and identifying the congestion level at the SCP, messages for communicating the SCP congestion level back to the SSPs, and procedures in the SSPs for throttling back the traffic. The ACG controls are all based on indirect routing of SCP queries. A traffic control item is identified by its Global Title Address (GTA) and Translation Type (TT), which are converted at the Signaling Transfer Point (STP) to the signaling point code of the destination SCP and SubSystem number (SSN) of the particular application or application set at that SCP. An ACG request to a SSP tells it to regulate sending the traffic using specific gap interval and duration. The ACG control can be initiated from the SCP in two ways: (1) automatically via SCP initiated code control; and (2) manually via the SMS Originated Code Control (SOCC). The manual SOCC method complements the automatic SCP method.
Having regard to the automatic SCP controls, when the SSP receives an ACG message with a control cause indicator of ISCP Overload,, it places the TT and 6-digit GTA on the SCP overload controls list. Timers for both gap interval and duration are started by the SSP when the control is added. Subsequent calls being processed by the SSP that generate queries with a called or charged number, matching the 6 digit code for the given TT are gapped until a period of time equal to the gap interval expires. After the gap interval expires the SSP allows the next applicable query to proceed normally. After this query has been sent, the SSP resumes blocking for another period of time equal to the gap interval. This cycle continues until a period of time equal to the duration has passed. The SCP overload control is removed from the controls list when the duration expires.
For the manual SOCC controls, when the SSP receives an ACG message with Control Cause Indicator of xe2x80x9cSMS Originatedxe2x80x9d, it places the xe2x80x9cTT and 3-, 6-, 7-, 8-, 9-, or 10-digit GTAxe2x80x9d control on the SOCC controls list. Timers for both gap interval and duration start when that control is added. After the control with a TT and GTA is added to the SOCC controls list and the gap interval timer has been started, calls which generate queries with xe2x80x9ccalled or charged number +TTxe2x80x9d matching the GTA+TT in the SOCC controls list are gapped until the gap interval expires. After the gap interval expires, the SSP allows the next applicable query to proceed normally. After this query has been sent, the SSP resumes blocking for another period of time equal to the gap interval. This cycle continues until a period of time equal to the duration has passed. The control is removed from the SOCC controls list when the duration expires.
Code gapping is a form of rate control. The SSP uses code gapping to regulate the queries destined to the SCP. Code gapping limits the number of initial queries per second, which is exemplified in FIG. 2. The arrows represent time when queries would normally be sent from the SSP to the SCP. When gapping is initiated, all queries from the source are blocked during the first gap interval, after which the next query may pass. Once a query passes, then all queries are blocked for the following gap. At most one query per gap interval will pass. This pattern repeats until the duration timer expires or the call gapping is de-activated.
FIG. 3 illustrates by way of example operation of code gapping control, wherein a duration of 15 seconds and gap interval of 5 seconds is employed. As shown in the figure, when the SSP receives an ACG request from an overloaded SCP, it initializes a duration timer and a gap timer. From 3 to 8 seconds, queries to the SCP are blocked (that is, no queries are sent to the SCP). When the gap timer expires, the next query is sent to the SCP. When the SSP sends a query to the SCP, it resets the gap timer (as shown at the 16th second), and the SCP processes the query and checks to see if the control should stay active. The SSP blocks queries from the 16 to 18 seconds, after which the duration timer expires. From the 18 seconds onward, queries are sent to SCP.
A potential problem with conventional code gapping may be an unfair throttling of SSP traffic. The SSP uses a gap interval and duration to regulate queries to the SCP and sends excess queries to reorder tone or announcement. When gapping is initiated, all queries from the SSP are blocked during the first gap interval, after which the next query may pass. Once a query passes then all queries are blocked for the following gap interval. Thus at most one query per gap interval will pass. The pattern of one query accepted followed by an interval in which all are blocked repeats until a duration timer expires. In this mechanism the same gap interval and duration are applied to all SSP offices. The control throttles large office much more severely than small offices. This results in unfair treatment between large and small offices. The control alternatingly turns traffic on and off, and the off period may be too long. Further, large offices can be expected to throttle a higher percentage of traffic than smaller offices. This mechanism does not take the SSP office size into consideration.
Another deficiency of conventional code gapping may be poor SCP resource utilization in connection with a load sharing SCP group. Operating companies replicate services on multiple SCPs for load sharing and reliability. An illustration of replicated SCPs (or Load Sharing SCPs) deployment is shown in FIG. 4. Typically, each SCP in the group is identified by the same point code and the STP cyclically selects each SCP in sequence to process respective queries which it receives from SSPs.
If one SCP in the load sharing SCP group is overloaded, it tells the SSPs to regulate the traffic destined to it. Since the SSPs view the load sharing SCP group as a single entity and the traffic control item is identified by its Global Title Address (GTA) and Translation Type (TT), the SSP applies the control to all calls that generate queries with matching GTA/TT. For example, if one of the multiple SCPs, say SCP-A, in a load sharing SCP group sends an overload control request to the SSP, all calls which match the GTA/TT under control will be blocked by the SSP even if the other SCPs in the group, namely SCP-B could process those queries. This results in poor SCPs resources utilization.
Yet another problem may be control instability. If SCP-B is not overloaded, it might request the SSP to remove the control. This results in control request and removal messages exchanges between the SSP and the load sharing SCP group. Excessive messages between the SSPs and load sharing SCP group may result in network traffic congestion and network performance degradation.
This problem further results in the instability of the controls. For two SCPs in the load sharing group, a control could be activated by one SCP and removed by the other constantly. The SCP under congestion will be processing queries not being blocked by the SSP and might get in severe overload state. This may happen, for example, in the period between the moment where the control is removed by SCP-B and the moment where a new control is activated by SSP, which is represented by the xe2x80x9cdangerxe2x80x9d zone in FIG. 5. This problem exists because the replicated SCPs do not communicate between each other to synchronize their active controls lists. One SCP does not know that another SCP requested a control for the common service SubSystem Number (SSN).
It is, therefore, desirable to resolve at least some of the identified load sharing SCPs traffic management control problems.
It is an object of the present invention to provide a new and improved load sharing service control point group.
The invention, therefore, according to a first broad aspect provides a method for synchronizing operation of a plurality of service control points (SCPs) in a load sharing group, comprising the steps of: maintaining, by each SCP, respective controls lists for the plurality of SCPs, each controls list identifies controls which are active at the corresponding SCP; generating a new control by any one SCP of the plurality of SCPs in the load sharing group; at the any one SCP, updating the controls list corresponding to itself to add the new control and sending an add control signal which identifies the new control to all other SCPs of the plurality of SCPs in the load sharing group; and at each of the other SCPs, updating the controls list corresponding to the any one SCP, that each maintains, to add the identified new control.
In accordance with a second broad aspect of the invention, there is provided a load sharing group of service control points (SCPs), comprising: two SCPs; and a communications link interconnecting the two SCPs.
In particular, the two SCPs each maintains a first controls list which identifies active controls at that SCP and a second controls list which identifies the active controls at the other SCP.
More particularly, when either of the two SCPs adds a new control to its first controls list, that SCP sends a subsystem congestion message which identifies the new control, over the communications link, to the other SCP which in response updates its second controls list by adding the identified new control. Furthermore, when either of the two SCPs removes an existing control from its first controls list, that SCP sends a subsystem available message which identifies the existing control, over the communications link, to the other SCP which in response updates its second controls list by removing the identified existing control.